Method and system for providing secure key distribution in a communication system

ABSTRACT

A method and system for providing secure authenticated cryptographic key distribution in a communication system having properties very similar to a Two-Party Authentication Protocol. A new group key is distributed by a server to a selected group of users in the system. A braided structure of the messages, sent by the server to each user, allows authentication and, at the same time, secure and secret key distribution. Moreover, the braided structure makes it possible to construct minimal-length protocol messages.

TECHNICAL FIELD

The present invention relates in general to secure communication systemsand in particular to secure cryptographic key distribution in acommunication system. Still more particularly, this invention relates tosecure authenticated key distribution in a communication system.

BACKGROUND OF THE INVENTION

Authentication protocols and key distribution protocols are known in theart.

A two-party authentication protocol (hereafter simply referred to as2PAP) is described in R. Bird, I. Gopal, A. Herzberg, P. Janson, S.Kutten, R. Molva, M. Young: Systematic Design of Two-PartyAuthentication Protocols, Proceeding of Crypto '91, August 1991. In thedescribed 2PAP, two users authenticate each other by transmittingchallenges and using a shared secret key. This protocol has been shownto be secure against an important class of attacks known as interleavingattacks. Such attacks are based upon the adversary's ability to useeither:

legitimate flows obtained from past executions of the protocol or

protocol flows elicited by the adversary from legitimate parties.

A family of key distribution protocols (hereinafter simply referred toas KDP) has been subsequently realized in an actual network securityservice, KryptoKnight, described in R. Molva, G. Tsudik, E. VanHerreweghen, S. Zatti: KriptoKnight Authentication and Key DistributionService, Proceeding of ESORICS 92, October 1992, Toulouse, France.

In a two-party key distribution protocol (hereinafter simply referred toas 2PKDP) a user distributes to another user a new secret key, using analready previously secret shared key.

In a three-party key distribution protocol (hereinafter simply referredto as 3PKDP) and in a multi-party key distribution protocol (hereinaftersimply referred to as MPKDP), as described in U.S. Pat. No. 4,649,233,there is a user (often called "server") that shares a correspondingmaster user key with each of the other users; each master user key isknown only to the server and the corresponding user. When a group ofusers (two or more) want to exchange secrets, since they do not share acommon key, they have to rely on collaboration with the server. Onrequest, the server generates and distributes a new group key for two(or more) selected users.

Key distribution is particularly difficult--because of timeconstraints--in communication system that provide for dynamic routingfunctions, enabling the continuation of routing, broadcasting, andmulticasting (sending a message to a sub-set of users along a path or aset of paths) in the presence of changes. Such dynamic routing functionsare per se known in the art, see for example Bertsekas-Gallager: DataNetworks, Prentice-Hall, 1987, section 5.3.

SUMMARY OF THE INVENTION

There are some drawbacks with this prior art. The key distributionprotocols known in the art have not been shown sufficiently secure; atleast not insofar as the 2PAP described by Bird et al., i.e., they arebelieved but have not been shown to resist any kind of attacks such asinlet leaving attacks or cut-and-splice attacks, for instance.

In addition, some do not guarantee integrity of the key beingdistributed, i.e. they do not guarantee that the key being distributedcannot be modified by an adversary. These limitations are particularlytrue of protocols with minimal-length messages for secure authenticatedkey distribution.

The above drawbacks of the prior art are overcome by the invention asclaimed.

The present invention provides a method and system that have beenmathematically demonstrated to be as secure as 2PAP, in particularagainst interleaving attacks, owing to a braided structure of theprotocol messages. The basic two-party key distribution (andauthentication) protocol can in turn be used as a basic building blockfor constructing more elaborate, e.g. three-party, multi-party orinter-domain, key distribution protocols. The braided structure, inaddition, guarantees the integrity of the key being distributed.Besides, this authenticated key distribution protocol requires minimallength protocol messages, and it is as compact as possible in both thenumber and the size of messages exchanged.

All this can be achieved with minimal computational requirements andwithout the necessity of using encryption/decryption functions.

The foregoing and other objects, features, and advantages of theinvention will be apparent from the following more particulardescription of a preferred embodiment of the invention, as illustratedin the accompanying drawing.

DESCRIPTION OF THE DRAWINGS AND NOTATIONS USED

The invention is described in detail below with reference to thefollowing drawings:

FIG. 1 is a pictorial representation of a communication system which maybe utilized for the implementation of the method and system of thepresent invention.

FIG. 2 depicts the 2PAP of the prior ad.

FIG. 3 is a high level logical flow chart illustrating an example of thetwo-party authentication key distribution protocol according to thepresent invention.

FIG. 4 depicts the message flow of an example of 2PKDP according to thepresent invention.

FIG. 5 is a high level logical flow chart illustrating an example of thethree-party authentication key distribution protocol according to thepresent invention.

FIG. 6 depicts the message flow of an example of 3PKDP according to thepresent invention.

FIG. 7 depicts the message flow of an example of MPKDP according to thepresent invention.

FIG. 8 depicts the message flow of an example of an optimized 3PKDPaccording to the present invention.

The following terminology is adopted throughout the description:

A,B,C: full user names; all names are assumed to be distinct. Thesenames are, for example, 64-bit values obtained either by directly codingthe identity or by applying a hash function to reduce the originalcoding of the name into a 64-bit field.

S: full name of the authentication server; S is a user assumed to beuniversally trusted by all constituent users.

N_(ab) : all symbols beginning with N are random challenges or nonces,i.e. unpredictable, used-only-once random numbers; created for thatspecific occasion unit of freshness information. The first letter of thesubscript refers to the user that originated the nonce while the secondletter in the subscript identifies the challenged target user (e.g.,N_(ab) is a nonce generated by A and sent to challenge B); K_(ab) : allsymbols beginning with K are keys. The subscript letters identify theusers sharing that key (e.g., K_(ab) is the key shared between A and B);+: exclusive OR or XOR function.

E_(K) (X): encryption of plaintext block X under key K. We use the termencryption to refer to a single-block transformation of cleartext input.This includes traditional encryption functions such as DES (described inNational Bureau of Standards, Federal Information Processing Standards,National Bureau of Standards, Publication 46, 1977) as well as strongone-way functions (no one can invert) such as MD5, when the key is usedas a suffix and/or prefix (described in R. Rivest: The MD5 MessageDigest Algorithm, Internet DRAFT, July 1991). In the case of DES, both Kand X are assumed to be not longer than the basic block size of theunderlying encryption function, i.e. 64 bits. (Such assumptions areirrelevant for many one-way hash functions such as MDS, whichaccommodate any parameter size by definition.)

FUNC(x,y,z): cryptographic function dependent upon arguments x,y,z; afunction may depend on all or only some of its arguments. All functionsgenerate results of a size equal to the basic block size of theunderlying cryptographic algorithm, e.g. 64 bits for DES, 128 for MDS,etc.

A→B X: this notation captures a single protocol flow; it denotes that Asent a message X to B.

DETAILED DESCRIPTION

With reference now to the figures and in particular with reference toFIG. 1, a communication system (100) is represented. Users A(101),B(102), C(103) can reside in various locations which are computers,terminals, local area networks, connected by a set of links (104, 105,106, 107, 108). One (or more) of these users may work as a server S(109) for secure key distribution. A common method is that a table ofmaster user keys is kept in safe storage at the server (K_(as) is themaster key shared by the server and a user whose identification is A;similarly K_(bs) is the key shared with B, and so on). Each user canalso have his master user key stored in its safe storage device(encrypted file, special hardware, a smart card, etc.).

FIG. 2 shows the basic secure 2PAP, described by Bird et al. in theprior art, between two users (A and B) sharing a common key K_(ab). Theprotocol execution begins at block 201 with the initiator party Atransmitting its identity A and a nonce N_(ab) to the second user B.Upon receiving the message from A, the value of an authenticationfunction AUTH(K_(ab),N_(ab),N_(ba),B), based upon the shared key thenonce N_(ab), a new nonce N_(ba) generated by B and the identity B ofthe message originator is computed by the second user B. Referring nowto block 202, the value of this authentication function and the nonceN_(ba) are transmitted from B to A. Upon receiving the message from B,the first user A re-computes the value of the authentication functionAUTH(K_(ab),N_(ab),N_(ba),B) and compares it with its counterpart in themessage sent by B; a match results in authentication of B. The firstuser A then computes the value of another authentication functionACK(K_(ab),N_(ab),N_(ba)), based upon the shared key K_(ab), the nonceN_(ab) and the nonce N_(ba), in order to complete two-wayauthentication. Referring now to block 203, the value of theauthentication function ACK(K_(ab),N_(ab),N_(ba)) is sent from A to B.Upon receiving the message from A, the user B re-computes the value ofthe authentication function ACK(K_(ab),N_(ab),N_(ba)) and compares itwith its counterpart in the message sent by A; a match results inauthentication of A.

TWO-PARTY KEY DISTRIBUTION PROTOCOL (2PKDP)

FIG. 3 depicts an example of a secure two-party authenticated keydistribution protocol between two users A and B according to the presentinvention. It is assumed that A and B share a common key K_(ab) prior toprotocol execution.

The protocol execution begins at block 301 with the initiator party Atransmitting its identity A and a nonce N_(ab) to the second user B,which can be considered as acting like a server to A. The second user Bthen generates a new key K_(ba) at block 302, which is held in a securefashion and meant only to be used by A and B. The value N_(ba) of anauthentication function AUTH(K_(ab),N_(ab),K_(ba),B), based upon atleast the shared key K_(ab), the nonce N_(ab), the new key K_(ba) andthe identity of B is computed by the second user B at block 303. Thefunction AUTH(K_(ab),N_(ab),K_(ba),B) can be an authenticationexpression based on the shared key K_(ab) ; one example of AUTH is(where all encryption is performed with key K_(ab)):

    E(B+(E(N.sub.ba +E(N.sub.ab ))).

The same user B then computes at block 304 the value of a functionBRAID(K_(ab),N_(ba),K_(ba)), based upon at least the shared key K_(ab),the value N_(ba) of the authentication functionAUTH(K_(ab),N_(ab),K_(ba),B) and the new key K_(ba). The function BRAIDcan be an encryption function or a masking expression MASK=E_(K).sbsb.ab(N_(ba)) computed by encryption of the value N_(ba) under the shared keyK_(ab), XOR-ed with the new key K_(ba) :

    E.sub.K.sbsb.ab (N.sub.ba)+K.sub.ba.

Referring now to block 305, the value of the authentication functionAUTH(K_(ab),N_(ab),K_(ba),B) and the value of the functionBRAID(K_(ab),N_(ba),K_(ba)) are transmitted from B to A. Upon receivingthe message from B, at block 306 the first user A can extract the newkey K_(ba) from the value of the function BRAID(K_(ab),N_(ba),K_(ba)),using the shared key K_(ab) and the value N_(ba). Assuming that thefunction BRAID is BRAID=E_(K).sbsb.ab (N_(ba))+K_(ba), A computes thevalue of the masking expression MASK=E_(K).sbsb.ab (N_(ba)) and thenextracts the new key K_(ba) by XOR-ing the value of the functionBRAID=E_(K).sbsb.ab (N_(ba))+K_(ba) with the value of the maskingexpression:

    K.sub.ba =E.sub.K.sbsb.ab (N.sub.ba)+K.sub.ba +MASK=E.sub.K.sbsb.ab (N.sub.ba)+K.sub.ba +E.sub.K.sbsb.ab (N.sub.ba)

If the user is indeed the user he claims to be by the identity sent to Bin block 301, he has the key K_(ab) and can obtain the new key K_(ba).If the user is impersonating the user A, he will not have the keyK_(ab), and will not be able to obtain the new key K_(ba). Referring nowto block 307, the first user A re-computes the value of theauthentication function AUTH(K_(ab),N_(ab), K_(ba),B) and compares itwith its counterpad in the message sent by B; a match results insuccessful, authenticated (and secret) distribution of the new keyK_(ba). The process then passes to block 308, where the first user Acomputes the value of another authentication functionACK(K_(ab),N_(ab),K_(ba)), based upon at least the shared key K_(ab),the nonce N_(ab) and the new key K_(ba), in order to complete two-wayauthentication. The function ACK can be an authentication expressionbased on the shared key K_(ab) ; one example of ACK is (where allencryption are performed with key K_(ab) ):

    E(K.sub.ba +E(N.sub.ab)).

Referring now to block 309, the value of the authentication functionACK(K_(ab),N_(ab),K_(ba)) is sent from A to B. The process ends at block310, where the user B re-computes the value of the authenticationfunction ACK(K_(ab),N_(ab),K_(ba)) and compares it with its counterpartin the message sent by A; a match results in authentication of A.

The distinctive feature of the braided structure of the BRAID functionis important to achieve both authentication and, at the same time, keydistribution. Moreover, the braided structure makes it possible toconstruct a minimal-length protocol message. This is because it isimpossible to distribute an unpredictable random quantity (in secret)and simultaneously authenticate the quantity being distributed with amessage of length less than two data units. The proposed two-party keydistribution protocol is then extremely compact in both the number andthe size of messages and this facilitates its application at any layerin the protocol hierarchy. Furthermore, as described in the following,the protocol is resistant to all interleaving attacks. All this isachieved with minimal computational requirements and without thenecessity of using encryption/decryption functions (which are a strongercryptographic tool, not always available).

DISCUSSION OF SECURITY

For simplicity and clarity of exposition, we will refer to the exampleof 2PKDP shown in FIG. 4.

Authentication

The first step in demonstrating the security of the proposed 2PKDP is toshow equivalence between it and 2PAP. In other words, we need to supportthe statement that the proposed protocol provides a means for two-partyauthentication with security equal to that of 2PAP. If we can prove thisequivalence, then it follows that the proposed protocol inherits thebasic properties of 2PAP, namely, resistance to interleaving attacks. Ofcourse, protocol goals other than authentication cannot be inheritedfrom 2PAP. In particular, the proposed protocol will be shown to meetthe additional requirement of non-disclosure of the key beingdistributed.

We begin with some initial assumptions about key distribution protocolsat large:

A key is always generated by one party.

A key being distributed must be a random, unpredictable quantity. If Aand B engage in a 2PKDP and B generates a key, then neither A nor anyother party can predict this key.

Keys are never re-used.

These assumptions lead to an important observation that afreshly-generated key is very similar to a nonce; in fact, the onlydifference between a nonce N_(ba) and a new key K_(ba) is that N_(ba) iscommunicated in the clear while K_(ba) is kept secret.

We can observe now that the only difference between the two protocols isthe so called `nonce` field of the second message. In 2PAP (202), thenonce field is simply N_(ba), while in 2PKDP (402) it is the morecomplex braid function expression E_(K).sbsb.ab (N_(ba))+K_(ba). Thepurpose of this expression is to conceal the key, i.e. K_(ba), which isused as a nonce (we consider the question of key confidentiality later).In order to demonstrate the equivalence of respective nonce fields,three issues must be addressed:

Is K_(ba) a nonce?

If K_(ba) is not a true nonce, then the equivalence does not hold.However, as noted earlier, nothing distinguishes a key from a nonceother than the fact that a key is kept secret. In particular, the rulesand the procedures of generating keys and nonces are quite the same.

Is N_(ba) a nonce?

Since K_(ba) is a true nonce, N_(ba) is a result of a strong one-wayfunction of (among other variables) K_(ba), we conclude that N_(ba) isalso a nonce.

Is there a one-to-one relationship between E_(K).sbsb.ab (N_(ba))+K_(ba)and K_(ba) ?

Or, equivalently, does there exist a distinct value N_(ba) such that:E_(K).sbsb.ab (N_(ba))=E_(K).sbsb.ab (N_(ba)). Under the assumption thatE_(K).sbsb.ab is a strong encryption function such as DES, this isclearly impossible since, otherwise, decryption would not be one-to-one.If, on the other hand, E is a strong one-way hash function (e.g. MD5)which produces a fixed-size digest of its input, different input valuescan be hashed into an identical digest. The issue is then the difficultyof computing N_(ba). In MD5, for example, the probability of any giveninput hashing into a known digest (in our case, even the digest isunknown) is ##EQU1## (impossible in practice).

Key-distribution

We now consider key distribution which is the added feature of theproposed 2PKDP. Strong authentication is not sufficient for achievingsecure key distribution thus the results of the previous section are notapplicable in this context.

The first issue is the definition of secure key distribution. For thepurpose of key distribution, a protocol is considered secure if:

Non-disclosure:

The key being distributed cannot be obtained by the adversary (that is,without any assistance from either A or B).

Independence:

Knowledge of one key cannot be used to obtain other keys. Here we assumethat the key being distributed will not be subsequently used as theencryption key in another 2PKDP. (The new key may, for example, be usedfor computing integrity checks on data messages exchanged between A andB).

Integrity:

The key being distributed cannot be modified by the adversary.

Non-disclosure

Assuming no collusion with a legitimate party, disclosure of a key ispossible only if the adversary is somehow able to obtain the MASK valuei.e., E_(K).sbsb.ab (N_(ba)). However, this is impossible since eachMASK is, in effect, a result of a one-way transformation of N_(ba). Thisimplies that the adversary must either: 1) possess the encryption key,K_(ab), or, 2) somehow be able to elicit the desired MASK value from oneof the legitimate parties. The former is assumed to be a non-issue whilethe latter deserves a closer look.

The adversary can try to obtain the MASK value by interrogating B andpretending to be A. However, no matter what value the adversary sends toB, B always generates a fresh key in message (402). It is the freshnessof the new key that makes it impossible for the adversary to obtain anyuseful information. In fact, it is quite irrelevant what the adversarytries to send to B since N_(ba) =AUTH (K_(ab),N_(ab),K_(ba),B) isstrongly dependent on the freshly-generated K_(ba).

Alternatively, the adversary can try to elicit information from A. Thisis significantly harder because A responds with message (403) only ifmessage (402) is authentic. Therefore, the adversary must be able togenerate expressions of the type in message (402) which is impossiblesince both cryptographic operations in message (402) are computed overA's random challenge, N_(ab).

Independence

We now suppose that the adversary has somehow managed to discover a keyK_(ba) ^(i) from one of the runs of 2PKDP. Furthermore, he has done sowithout any explicit cooperation with either A or B. The most importantadditional piece of information that the adversary can thereby obtainis: E_(K).sbsb.ab (N_(ba) ^(i))=MASK^(i).

Now, since MASK^(i) is the encryption of N_(ba) ^(i) under the long-termkey, K_(ab), the adversary can discover a plaintext,ciphertext!block-pair which he can later use for trying to break K_(ab). This is,however, a danger commensurate with the presumed breach of securitywhich resulted in the adversary's discovery of K_(ba) ^(i).

The remaining question is whether or not the adversary can use thenewly-acquired information to attack the protocol by:

1. discovering a key K_(ba) ^(i) (i≢j) from any other protocol run(either past or future);

2. successfully distributing K_(ba) ^(i) to A in another protocol runwhile posing as B.

As stated earlier, MASK is a result of a one-way function of N_(ba).Recall also that N_(ba) is, itself, a one-way function of N_(ab), K_(ba)and B. This essentially precludes any possibility of type 1 attacks.

An attack of type 2 requires that the adversary be able to construct amessage of the form (i≢j):

    N.sub.ba.sup.i =AUTH(K.sub.ab,N.sub.ab.sup.j,K.sub.ba.sup.i,B), E.sub.K.sbsb.ab (N.sub.ba.sup.i)+K.sub.ba.sup.i where K.sub.ba.sup.j ≢K.sub.ba.sup.i.

This, in turn, is possible only if the adversary is able to produce afresh value of N_(ba) ^(j) which includes the computation of the AUTHexpression over a fresh nonce N_(ab) ^(j). The adversary cannot obtainN_(ba) ^(i) via oracle attacks since the party he chooses to interrogatewill reply with a message implicitly re-freshed with its own nonce.

Integrity

The integrity of the key being distributed is not one of the foremostsecurity features of a KDP. A pure key distribution protocol need notconcern itself with the integrity of the key as long as the key cannotbe modified to a particular value selected by the adversary. Forexample, some KDPs known in the art, as described in R. Bird at al. arevulnerable to key modification attacks since the key itself is notauthenticated but, rather, only distributed. Nonetheless, this is notconsidered to be a bug in the protocol because the adversary cannotchange the key to a known value; he can only offset a key by a knownvalue.

On the other hand, attacks of this sod are not feasible with the present2PKDP since key modification requires simultaneous modification of theauthentication expression: AUTH(K_(ab),N_(ab),K_(ba),B).

THREE-PARTY KEY DISTRIBUTION PROTOCOL (3PKDP)

FIG. 5 depicts a high level logical flow chart of a three-partyauthenticated key distribution protocol according to the presentinvention. The objective of a 3PKDP is to distribute a fresh group keyto a group of users (two parties in this case). It is assumed that thereexists a mutually-trusted third party typically referred to as theauthentication server (S). It is assumed that all the users of the groupshare a corresponding secret master user key prior to protocol execution(K_(as) for A-S and K_(bs) for B-S). Each of said user key is know onlyto the server and the corresponding user. In the protocol of thisexample there is an initiator, denoted as A, which starts thecommunication. It is assumed that the group is determined in such a waythat A knows who takes part in it. The protocol is started by theinitiator A who first identifies the other parties (users) in the group.

A secure 3PKDP must satisfy much the same conditions as a secure 2PKDPwith one added requirement:

Neither party must be able to alter the group key being distributed.

More generally, we assume that one of the legitimate parties (A or B)may exhibit arbitrary `byzantine` behavior (that it could impersonateanother party that is registered with S). Of course, not all types ofsuch threats can be addressed within the protocol. For example,unauthorized disclosure of a session key cannot be prevented. However, asecure 3PKDP must be defended against attacks by a legitimate party. Infact, a legitimate party exhibiting byzantine behavior can be viewed asa special case of an adversary (one armed with additional knowledge).

We obtain a secure 3PKDP by combining two instances (runs) of 2PKDP andone instance of 2PAP. Two users A and B each engage in a 2PKDP with theauthentication server S. A and B are each assumed to share a user secretkey with S, i.e., K_(as) and K_(bs). After the distribution of the newkey K_(ab), A and B engage in a 2PAP in order to confirm each other'sknowledge of K_(ab).

Referring now to block 501, the protocol execution begins with a firstuser A transmitting its identity A, a nonce N_(as) and the identity ofthe users (only B in this case) of the group other than A to the serverS. The server then generates a new group key K_(ab) at block 502, whichis held in a secure fashion and meant only to be used by the users ofthe group (A and B in this example). The value N_(sa) of anauthentication function AUTH(K_(as),N_(as),K_(ab),B), based upon atleast the user's key K_(as), the user's nonce N_(as), the group keyK_(ab) and the identity of the users (B in this case) of the group otherthan A is computed by the server at block 503. The server S thencomputes at block 504 the value of a functionBRAID(K_(as),N_(sa),K_(ab)), based upon at least the user's k_(as), thevalue N_(sa) and the group key K_(ab).

Referring now to block 505, the value of the authentication functionAUTH(K_(as),N_(as),K_(ab),B) and the value of the functionBRAID(K_(as),N_(sa),K_(ab)) are transmitted from S to A. Upon receivingthe message from S, at block 506 the first user A can extract the groupkey K_(ab) from the value of the user's functionBRAID(K_(as),N_(sa),K_(ab)), using the user's key K_(as) and the valueN_(sa).

Referring now to block 507, the first user A re-computes the value ofthe user's authentication function AUTH(K_(as),N_(as),K_(ab),B) andcompares it with its counterpad in the message sent by S; a matchresults in successful, authenticated (and secret) distribution of thegroup key K_(ab). The process then passes to block 508, where the firstuser computes the value of another authentication functionACK(K_(as),N_(as),K_(ab)), based upon at least the user's key K_(as),the user's nonce N_(as) and the group key K_(ab), in order to completetwo-way authentication.

Referring now to block 509, the value of the authentication functionACK(K_(as),N_(as),K_(ab)) is sent from A to S. The first 2PKDP ends atblock 510, where the server S re-computes the value of theauthentication function ACK(K_(as),N_(as),K_(ab)) and compares it withits counterpad in the message sent by A; a match results inauthentication of A.

Similar steps are now performed between the second user B and the serverS. Referring to block 511, the second user B transmits its identity B, anonce N_(bs) and the identity of the users (only A in this case) of thegroup other than B to the server S. The value N_(sb) of anauthentication function AUTH(K_(bs),N_(bs),K_(ab),A), based upon atleast the user's key K_(bs), the user's nonce N_(bs), the group keyK_(ab) and the identity of the users (A in this case) of the group otherthan B is computed by the server at block 512. The server S thencomputes at block 513 the value of a functionBRAID(K_(bs),N_(sb),K_(ab)), based upon at least the user's key K_(bs),the value N_(sb) and the group key K_(ab).

Referring now to block 514, the value of the authentication functionAUTH(K_(bs),N_(bs),K_(ab),A) and the value of the functionBRAID(K_(bs),N_(sb),K_(ab)) are transmitted from S to B. Upon receivingthe message from S, at block 515 the second user B can extract the groupkey K_(ab) from the value of the user's functionBRAID(K_(bs),N_(sb),K_(ab)), using the user's key K_(bs) and the valueN_(sb).

Referring now to block 516, the second user B re-computes the value ofthe user's authentication function AUTH(K_(bs),N_(bs),K_(ab),A) andcompares it with its counterpart in the message sent by S; a matchresults in successful, authenticated (and secret) distribution of thegroup key K_(ab). The process then passes to block 517, where the seconduser computes the value of another authentication functionACK(K_(bs),N_(bs),K_(ab)), based upon at least the user's key K_(bs),the user's nonce N_(bs) and the group key K_(ab), in order to completetwo-way authentication.

Referring now to block 518, the value of the authentication functionACK(K_(bs),N_(bs),K_(ab)) is sent from B to S. The second 2PKDP ends atblock 519, where the server S re-computes the value of theauthentication function ACK(K_(bs),N_(bs),K_(ab)) and compares it withits counterpad in the message sent by B; a match results inauthentication of B. The two users A and B then can authenticate eachother by a 2PAP. Referring to block 520, the first user A transmits itsidentity A and a nonce N_(ab) to the second user B. Upon receiving themessage from A, the value of the authentication functionAUTH(K_(ab),N_(ab),N_(ba),B), based upon at least the group key K_(ab),the nonce N_(ab), a new nonce N_(ba) and the identity B of the messageoriginator is computed by the second user B at block 521.

Referring now to block 522, the value of the authentication functionAUTH(K_(ab),N_(ab),N_(ba),B) and the nonce N_(ba) are transmitted from Bto A. Upon receiving the message from B, at block 523 the first user Are-computes the value of the authentication functionAUTH(K_(ab),N_(ab),N_(ba),B) and compare it with its counterpad in themessage sent by B; a match results in authentication of B. The processthen passes to block 524, where the first user computes the value of theauthentication function ACK(K_(ab),N_(ab),N_(ba)), based upon at leastthe group key K_(ab), the nonce N_(ab) and the nonce N_(ba), in order tocomplete two-way authentication.

Referring now to block 525, the value of the authentication functionACK(K_(ab),N_(ab),N_(ba)) is sent from A to B. The process ends at block526, where the second user B re-computes the value of the authenticationfunction ACK(K_(ab),N_(ab),N_(ba)) and compare it with its counterpad inthe message sent by A; a match results in authentication of A.

We note that the server can also play the role of a user (in addition toserver). The server can use the protocol to share a key with a groupwhich contains the server itself (as a member of the group), in whichcase the server can play both the role of the protocol server and therole of the user, omitting sending the group key and authenticationverification to itself (which is not needed), but only to a sub-group ofusers consisting of the users of the group other than the server S. Inparticular, this can be used to refresh the keys shared by the serverand a user in a reliable way that makes sure that only the server andthe actual user can change the key they share. We note that if the groupconsists only of two users (e.g., A and S), the protocol becomes equalto the described 2PKDP.

DISCUSSION OF SECURITY

For simplicity and clarity of exposition, we will refer to the exampleof 3PKDP shown in FIG. 6.

Authentication

As with 2PKDP, the first issue we must address is the strength of 3PKDPas an authentication protocol. In other words, does the protocol achievepairwise authentication of (A,S), (B,S) and, finally, (A,B)?

Starting from the end of the protocol, it can be easily seen that,assuming secure distribution of K_(ab), the authentication protocolbetween A and B is as secure as the underlying 2PAP (in fact, it is2PAP.)

Viewed in isolation, 2PKDP between A and S is secure and so is 2PKDPbetween B and S. However, one important difference between 3PKDP and twounrelated runs of 2PKDP is that the nonce generated by S is the same inboth runs of 2PKDP (i.e., K_(ab)). This is not a problem as long as itcan be shown that the respective AUTH expressions remain uniquely `tied`to the particular run of 3PKDP. We address this issue by explicitlyincluding the name of the peer party in the calculation of each AUTHexpression, i.e., B is included in AUTH with K_(as) and A in AUTH withK_(bs). While this argument is not particularly crisp, we note that onesimple method for complete conformance with 2PKDP is to use K_(ab) +Ainstead of K_(ab) in AUTH with K_(as) and, similarly, K_(ab) +B insteadof K_(ab) in AUTH with K_(bs).

Key distribution

The non-disclosure and independence properties in 3PKDP are inheriteddirectly from 2PKDP. The integrity of the new key is a different matter.The side-effect of the same key being distributed to both parties, isthat an `insider` adversary, say B, can obtain the expression used tomask the key in the message from S to A. MASK_(a) =E_(K).sbsb.as(N_(sa))=E_(K) _(as) (AUTH(K_(as),N_(as),K_(ba),B)).

At the first glance, it appears that knowledge of this expression allowsB to modify K_(ab) to any selected K_(ab) with impunity. Nonetheless,the AUTH with K_(as) expression (enclosed in the same message) precludesthis attack since B cannot alter AUTH(K_(as),N_(as),K_(ab),B) to beAUTH(K_(as),N_(as),K_(ab),B)

On a related note, one advantage that B does gain as a result of 3PKDPis the knowledge of the cleartext-ciphertext pair of the form: N_(sa),E_(K).sbsb.as (N_(sa)). This poses a threat insofar as B is able todiscover K_(as) by means of a brute-force attack. However, the amount ofwork required on the average remains considerable, certainlycommensurate with what would be required to crack an AUTH expression inthe first place.

MULTI-PARTY KEY DISTRIBUTION PROTOCOL

FIG. 7 depicts the list of the messages exchanged in an example of asecure multi-party authenticated key distribution protocol from a serverS to a group of selected users (A, B and C in the example) according tothe present invention. In the protocol of this example there is aninitiator, denoted as A, which starts the communication. It is assumedthat the group is determined in such a way that A knows who is pad ofit. It is also assumed that all users of the group share a correspondingsecret user key prior to protocol execution (K_(as) for A-S, K_(bs) forB-S and K_(cs) for C-S). Each of said user keys is known only to theserver and a corresponding one of the users. The protocol is started bythe initiator A who first identifies the other parties (users) in thegroup.

The actual process flow implementing the above protocol messages can beplainly derived from FIG. 7.

In FIG. 7, the Multi-Party Key Distribution Protocol (MPKDP) is obtainedby combining three runs of 2PKDP: A-S, B-S, and C-S with three runs of2PAP: A-B, A-C, B-C. The goal of the MPKDP is to distribute to allparties the new key K_(abc). After receiving K_(abc), A-B, A-C, and B-Cengage in a 2PAP to confirm each other's knowledge of K_(abc).

Referring to blocks 701,704 and 707, each of A, B and C, sends to serverS its identity, its own nonce (N_(as), N_(bs), N_(cs)), and theidentities of other group members: (B,C) for A, (A,C) for B and (A,B)for C.

Referring to blocks 702,705 and 708, server S generates a new keyK_(abc) which is held in a secure fashion and is meant only to be usedby the members of the group (A, B, and C in this example.) The values ofN_(sa), N_(sb), and N_(sc) are: AUTH(K_(as),N_(as),K_(abc),B,C),AUTH(K_(bs),N_(bs),K_(abc),A,C) and AUTH(K_(cs),N_(cs) K_(abc),A,B),respectively. Each is based upon at least the user's key (K_(as), K_(bs)or K_(cs)), the user's nonce (N_(as), N_(bs), or N_(cs)), the group keyK_(abc), and the identities of other group members ((B,C), (A,C) or(A,B)).

Server S also computes the value of the functions:BRAID(K_(as),N_(sa),K_(abc)), BRAID(K_(bs),N_(sb),K_(abc)), andBRAID(K_(cs),N_(sc),K_(abc)). Each of these functions is computed as inthe description of 3PKDP.

Finally, server S sends out to A: AUTH(K_(as),N_(as),K_(abc),B,C) andBRAID(K_(as),N_(sa),K_(abc)); to B: AUTH(K_(bs),N_(bs),K_(abc),A,C) andBRAID(K_(bs),N_(sb),K_(abc)); to C: AUTH(K_(cs),N_(cs) K_(abc),A,B) andBRAID(K_(cs),N_(sc),K_(abc)). Each of A, B, and C verifies itsrespective message and extracts the new key K_(abc).

Referring to blocks 702, 705 and 709, each user A, B, and C computes andsends to server S, respectively, the value ofACK(K_(as),N_(as),K_(abc)), ACK(K_(bs),N_(bs),K_(abc)) andACK(K_(cs),N_(cs),K_(abc)) whereof each is based upon at least theuser's key (K_(as), K_(bs), K_(cs)), the user's nonce (N_(as), N_(bs) orN_(cs)), and the group key K_(abc). Upon receipt of all three messages,S verifies each one using the corresponding values. This completes theauthenticated key distribution.

The remainder of the protocols (blocks 710 through 718) is devoted tothree runs of 2PAP to confirm to each of the three group members thatthe other members hold the new key K_(abc). Each of the 2PAP runs A-B,A-C, and B-C is identical to that in FIG. 2.

OPTIMIZATION

The protocol shown in FIG. 6 (similar considerations can be made aboutthe protocol of FIG. 7) was obtained by a straightforward combination of2PKDPs and 2PAPs. It requires a total of 9 messages and 3 bi-directionalcommunication flows (A-B, A-S, B-S). In order to reduce the number ofmessages and optimize the protocol some of the messages can beinterleaved. Moreover, it is not necessary for both A and B tocommunicate with S directly. A more realistic scenario would be suchthat all communication with S is either through A or B.

Referring now to FIG. 8, there is depicted a compacted version of a3PKDP. In this example A starts the execution, then passes itsinformation to B which passes A's information to S together with B'sinformation. In a counter-move, the server S sends all the informationto B, that distributes its piece of information to A. In order to makethe protocol insensitive to the order of communication inside the groupof users communicating with each other, tags are used so that aparticular user knows which particular piece of information it is to usein a stream of data.

Referring now to block 801, the protocol execution begins with aninitiating user, A, transmitting his identity, his nonce for S (N_(as)),his nonce for B (N_(ab)) and the name of the other user (B) to that userB.

At block 802, upon receipt of the information from user A, user Btransmits to S his own identity, the identity of the other use (A), hisnonce for S (N_(bs)) and A's nonce for S (N_(as)).

Referring now to block 803, server S generates a new key K_(ab) which isheld in a secure fashion and meant only to be used by A and B. The valueN_(sa) of an authentication function AUTH(K_(as),N_(as),K_(ab),B) basedupon at least the user's key K_(as), the user's nonce N_(as), the newkey K_(ab), and the identity of the other user B is computed. Server Sthen computes the value of a function BRAID(K_(as),N_(sa),K_(ab)), basedupon at least the user's key K_(as), the value N_(sa), and the new keyK_(ab).

Referring still to block 803, server S also computes the valueauthentication function AUTH(K_(bs),N_(bs),K_(ab),A) based upon at leastthe user's key K_(bs), the user's nonce N_(bs), the new key K_(ab), andthe identity of the other user A. Server S then computes the value of afunction BRAID(K_(bs),N_(sb),K_(ab)), based upon at least the user's keyK_(bs), the value N_(sb), and the new key K_(ab). Finally, server Stransmits AUTH(K_(as),N_(as),K_(ab),B), BRAID(K_(as),N_(sa),K_(ab)),AUTH(K_(bs),N_(bs),K_(ab),A) and BRAID(K_(bs),N_(sb),K_(ab)) to B.

Referring now to block 804, user B receives the above message andextracts the new key K_(ab) from the value of the user's functionBRAID(K_(bs),N_(sb),K_(ab)) using the key K_(bs) and the valueAUTH(K_(bs),N_(bs),K_(ab),A). Then, B authenticates the new key K_(ab)by verifying the authentication function AUTH(K_(bs),N_(bs),K_(ab),A)based upon at least the user's key K_(bs), the value N_(bs), the new keyK_(ab), and the identity of the other user A.

Then, B computes the value AUTH(K_(ab),N_(ab),N_(ba),B) based upon atleast the new key K_(ab), A's nonce N_(ab), B's nonce N_(ba) and theidentity of B. At the end of block 804, B transmitsAUTH(K_(as),N_(as),K_(ab),B), BRAID(K_(as),N_(sa),K_(ab)) to A. At block805, B transmits AUTH(K_(ab),N_(ab),N_(ba),B) and its nonce N_(ba) to A.Referring to block 806, user A receives the above message and extractsthe new key K_(ab) from the value of the user's functionBRAID(K_(as),N_(ab),K_(ab)) using the key K_(as) and the valueAUTH(K_(as),N_(as),K_(ab),B). Then, A authenticates the new key K_(ab)by verifying the authentication function AUTH(K_(as),N_(as),K_(ab),B)based upon at least the user's key K_(as), the value N_(as), the new keyK_(ab), and the identity of the other user B.

Then, A verifies the received value AUTH(K_(ab),N_(ab),N_(ba),B) basedupon at least the new key K_(ab), A's nonce N_(ab), B's nonce N_(ba),and the identity of B.

Still referring to block 806, user A computes the value of anotherauthentication function ACK(K_(as),N_(as) K_(ab)) based at least on theuser's key K_(as), the user's nonce for S (N_(as)), and the new keyK_(ab) in order to complete two-way authentication between A and S. UserA also computes yet another authentication functionACK(K_(ab),N_(ab),N_(ba)) based upon at least the new key K_(ab), A'snonce for B N_(ab), and B's nonce for A N_(ba). At the end of block 806,user A transmits to B ACK(K_(as),N_(as),K_(ab)) andACK(K_(ab),N_(ab),N_(ba)).

Referring now to block 807, user B receives ACK(K_(as),N_(as),N_(ab))and ACK(K_(ab),N_(ab),N_(ba)). First, user B recomputes the value of thefunction ACK(K_(ab),N_(ab),N_(ba)) and compares it with its counterpadin the messages received from A; a match results in the authenticationof A.

User B now computes the value of another authentication functionACK(K_(bs),N_(bs),K_(ab)) based at least on the user's key K_(bs), theuser's nonce for S (N_(bs)), and the new key K_(ab) in order to completetwo-way authentication between B and S. Then, user B transmits to SACK(K_(as),N_(as),K_(ab)) and ACK(K_(bs),N_(bs),K_(ab)).

Referring still to block 807, server S receivesACK(K_(as),N_(as),K_(ab)) and ACK(K_(bs),N_(bs),K_(ab)) sent by B.Server S first recomputes the value of the authentication functionACK(K_(as),N_(as),K_(ab)) and compares it with its counterpad in themessage received from B; a match results in the authentication of A.Next, server S first recomputes the value of the authentication functionACK(K_(bs),N_(bs),K_(ab)) and compares it with its counterpad in themessage received from B; a match results in the authentication of B.This completes the protocol.

We claim:
 1. A method for providing secure, authenticated distributionin a communication system of a key to be used by a group of selectedusers, the key being distributed from a server to a sub-group consistingof the users of said group other than said server, each user of saidsub-group sharing a secret user key with said server, said methodcomprising the steps of:transmitting (501,511) the user's identification(A), a user's nonce (N_(as)) and an identification (B) of a user of saidsub-group other than said transmitting user from each user of saidsub-group to said server through an available path of said system;generating (502) a new, common group key (K_(ab)) for all users of saidgroup by said server; computing (503,512) the value of a first functionfor each user of said sub-group by said server, said first functiondepending upon at least said user's key (K_(as)), said user's nonce(N_(as)), said group key (K_(ab)) and the identification (B) of the userof said group other than said user; computing (504,513) the value of asecond function for each user of said sub-group by said server, saidsecond function depending upon at least said user's key (K_(as)), thevalue of said user's first function and said group key (K_(ab));transmitting (505,514) the values of said user's first and secondfunctions from said server to each user of said sub-group through anavailable path of said system; extracting (506,515) said group key, byeach user of said sub-group, from the value of said user's secondfunction, employing said user's key and the value of said user's firstfunction; and re-computing (507,516) the value of said user's firstfunction by each user of said sub-group and considering authenticatedsaid extracted group key (K_(ab)) if said re-computed value is equal tothe value of said user's first function received by said server.
 2. Themethod according to claim 1, further comprising the steps of:computing(508,517) the value of a third function by each user of said sub-group,said user's third function depending upon at least said user's key(K_(as)), said user's nonce (N_(as)) and said group key (K_(ab));transmitting (509,518) the value of said user's third function from eachuser of said sub-group to said server through an available path of saidsystem; and re-computing (510,519) the value of said user's thirdfunction for each user of said sub-group by said server andauthenticating each user of said sub-group if said re-computed value ifequal to the value of said user's third function received by said user.3. The method according to claims 1 or 2, further comprising the stepof:each user of said sub-group authenticating (520 to 526) itself to anyother user of said sub-group by encrypting and exchanging informationwith said group key (K_(ab)) between said users.
 4. The method accordingto claims 1 or 2, wherein said first, second and third functions areencryption functions under said user's key (K_(as)).
 5. The methodaccording to claims 1 or 2, wherein said second function is anencryption function under said user's key (K_(as)) of at least saiduser's first function, exclusively OR-ed with said group key (K_(ab)).6. The method according to claim 5, wherein said group key (K_(ab)) isextracted by each user of said sub-group by re-computing the value ofsaid user's encryption function and XOR-ing said result with the valueof said user's second function.
 7. The method according to claims 1 or2, further characterized in that:the information to be transmitted fromeach user of said sub-group to the server is collected by one of theusers of the system and then transmitted from said one user to saidserver.
 8. The method according to claims 1 or 2, further characterizedin that:the information to be transmitted over the system is identifiedby a tag identifying the addressed user or server.
 9. A communicationsystem (100) for providing secure, authenticated distribution of a keyto be used by a group of selected users (101,102,103,109), the key beingdistributed from a server (109) to a sub-group of users (101,102,103)consisting of the users of said group other than said server, each userof said sub-group sharing a corresponding secret user key with saidserver, said system comprising:means for transmitting (501,511) theuser's identification, a user's nonce and an identification of a user ofsaid sub-group other than said user from each user of said sub-group tosaid server through an available path of said system; means forgenerating (502) a new, common group key for all users of said group bysaid server; means for computing (503,512) the value of a first functionfor each user of said sub-group by said server, said first functiondepending upon at least said user's key, said user's nonce, said groupkey and the identification of the user of said group other than saiduser; means for computing (504,513) the value of a second function foreach user of said sub-group by said server, said second functiondepending upon at least said user's key, the value of said user's firstfunction and said group key; means for transmitting (505,514) the valuesof said user's first and second functions from said server to each userof said sub-group through an available path of said system; means forextracting (506,515) said group key, by each user of said sub-group,from the value of said user's second function, employing said user's keyand the value of said user's first function; and means for re-computing(507,516) the value of said user's first function by each user of saidsub-group and considering authenticated said extracted group key if saidre-computed value is equal to the value of said user's first functionreceived by said server.
 10. The communication system according to claim9, further comprising:means for computing (508,517) the value of a thirdfunction by each user of said sub-group, said user's third functiondepending upon at least said user's key, said user's nonce and saidgroup key; means for transmitting (509,518) the value of said user'sthird function from each user of said sub-group to said server throughan available path of said system; and means for re-computing (510,519)the value of said user's third function for each user of said sub-groupby said server and authenticating each user of said sub-group if saidre-computed value is equal to the value of said user's third functionreceived by said user.
 11. The method according to claim 3, wherein saidfirst, second and third functions are encryption functions under saiduser's key (K_(as)).
 12. The method according to claim 3, wherein saidsecond function is an encryption function under said user's key (K_(as))of at least said user's first function, exclusively OR-ed with saidgroup key (K_(ab)).
 13. The method according to claim 4, wherein saidsecond function is an encryption function under said user's key (K_(as))of at least said user's first function, exclusively OR-ed with saidgroup key (K_(ab)).
 14. The method according to claim 3, furthercharacterized in that:the information to be transmitted from each userof said sub-group to the server is collected by one of the users of thesystem and then transmitted from said one user to said server.
 15. Themethod according to claim 4, further characterized in that:theinformation to be transmitted from each user of said sub-group to theserver is collected by one of the users of the system and thentransmitted from said one user to said server.
 16. The method accordingto claim 5, further characterized in that:the information to betransmitted from each user of said sub-group to the server is collectedby one of the users of the system and then transmitted from said oneuser to said server.
 17. The method according to claim 6, furthercharacterized in that:the information to be transmitted from each userof said sub-group to the server is collected by one of the users of thesystem and then transmitted from said one user to said server.
 18. Themethod according to claim 3, further characterized in that:theinformation to be transmitted over the system is identified by a tagidentifying the addressed user or server.
 19. The method according toclaim 4, further characterized in that:the information to be transmittedover the system is identified by a tag identifying the addressed user orserver.
 20. The method according to claim 5, further characterized inthat:the information to be transmitted over the system is identified bya tag identifying the addressed user or server.
 21. The method accordingto claim 6, further characterized in that:the information to betransmitted over the system is identified by a tag identifying theaddressed user or server.
 22. The method according to claim 7, furthercharacterized in that:the information to be transmitted over the systemis identified by a tag identifying the addressed user or server.